A man-in-the-middle attack (or middle-person attack) is an attack in which an adversarial device “inserts itself” between first and second victim devices which are attempting to communicate. The adversarial device makes the first and second victim devices believe that they communicate with each other, while they in fact communicate with the adversarial device, and the adversarial device relays messages between the first and second victim devices. Such an attack allows the adversarial device to read the communication between the two victim devices and to alter and insert messages that each of the two victim devices will believe came from the other victim device. It allows an adversarial device to eavesdrop on encrypted data without breaking the encryption scheme if he mounts an attack during the key establishment protocol (which is the phase of the communication when the two victim devices select the key to be used for encryption.)
To date, only one type of defense has been proposed to prevent this type of attack, and it involves the use of public key cryptography, and requires the use of a certification infrastructure. This, in turn, forces users into trust relationships with a certification authority, and requires substantial computational resources on behalf of the devices performing key exchange. While consumer computers can perform the type of operations needed without any problem, less powerful and less costly devices will not. For example, it is not certain that cellular phones will have the capability, and it is almost certain that cordless headsets for phones will not. Therefore, current methods prevent a large number of products from performing such a safe key exchange (as exemplified by a recent attack on Bluetooth by the author of this application.) A second problem, not related to computational power, is that even if the two victim devices do have sufficient computational resources to perform a public-key based exchange, it is difficult for humans to ascertain that the public keys delivered in fact match the device with which the key exchange should occur. For example, if two cell phone users wish to exchange a key, how could one user know the user identifier of the other person? (While naming, e.g., “John Doe” helps, it may not suffice, as there may be several John Does, and users have a difficult time detecting small typographical differences, such as distinguishing “John Doe” from “Jon Doe”).
Even worse, if one of the devices does not have an operator, the identification process becomes more difficult. For example, if a visitor to a cyber café wishes to establish a secure connection with a printer in the store, should he trust the name “printer”, “Starbucks printer”, or “Starbucks printer”? (Phrases “Starbucks printer” and “Starbucks printer” differ in that the first has one space in between the two words and the second has two spaces). If another café visitor names his phone any of the previous, there is a severe risk for a man-in-the-middle attack. Therefore, even if all devices were powerful enough to perform a public-key supported key exchange, human error might open up vulnerabilities.
It has been shown for the case involving Bluetooth that the use of PINs does not guarantee to solve the above problem, either. If too long PINs are used, the risk for human error or bad PINs increases. If short PINs (anything less than 20–30 digits) are used, then so-called dictionary attacks can be mounted on the key exchange.